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I. INTRODUCTION 



Fleet readiness is dependent on the effective management 
of materiel inventories. The logistics system which 
provides for provisioning and resupply of operating forces 
is extremely complex when viewed in the context of the 
Navy' s global commitments and austere funding levels. Yet 
it is this logistics system which becomes all the more 
critical in times of national emergency. It is then when it 
becomes a life's blood, determining the range of deployment, 
endurance and even the tactics which can be employed. 

Nowhere is this more evident than in the area of 
conventional ammunition management. The very nature of this 
commodity requires strict accounting and access to current 
information at all echelons of the Navy--a task made more 
complicated by the worldwide prepositioning of stock and the 
necessity for monitoring its serviceability. In response to 
this challenge the Conventional Ammunition Integrated 
Management System (CAIMS) was established. 

The CAIMS is the Navy's central repository of ammunition 
inventory information. Program policy guidance for CAIMS is 
provided in [Ref. 1] with specific afloat policies 
implemented and further defined by Fleet Commanders. 
Administered by the Navy Ship's Parts Control Center ( SPCC) , 
CAIMS is designed to be the single point of reference in the 
Navy for information regarding the worldwide status of non- 
nuclear expendable ordnance [Ref. 2]. Accordingly, CAIMS 
performs multiple tasks and serves many users. Swanson 
[Ref. 3] notes that CAIMS is not only an inventory 
management tool, it is also used for readiness assessment; 
operational decision making; as a source of technical data; 
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for procurement, production and renovation planning; 
requirements determination; and in budget development. 

Ammunition management is also big business. Navy 
ammunition procurement reached a high of $988 million during 
the Vietnam War [Ref. 3:p. 24]. In June 1980 the Navy* s 
ammunition inventory was valued at $6. 7 billion with $3 
billion distributed to fleet units and overseas shore 
activities. These facts underscore the necessity for 
accurate and timely information concerning system inventory 
status: a major objective of the GAINS. However, recent 

audits have questioned this system's ability to provide the 
required responsive support. 

One such audit conducted by the U. S. General Accounting 
Office (GAO) [Ref. 4] has criticized the Navy's ability to 
maintain accountability over conventional ammunition. Based 
upon on-site audits of local records and comparison with 
data provided by the GAINS, GAO found significant 
discrepancies between recorded data and actual on-hand 
assets. This was evident from a seventy percent error rate 
in account balances maintained by one naval magazine and by 
$8.5 million in gain and loss adjustments recorded between 
October 1979 and December 1980 by the same activity. The 
report concluded that the GAINS data was unreliable and that 
the system is inadequate to maintain ammunition 
accountability. The report' s recommendations are summarized 
below: 

1. Develop a program to expedite the reconciliation of the 
Navy s central inventory records with storage records 
and investigate the causes of significant adjustments. 

2. Develop a capability to effectively monitor the status 
of ammunition transactions. 

3. Process suspended ammunition in a more timely manner. 
Suspended ammunition includes those items and 
components which are not ready for unrestricted use and 
that cannot be made serviceable using immediately 
available maintenance or repair capability. 
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4. Require interim accountability for ammunition 
designated for further transfer. 

A subsequent GAO audit [Ref. 5] reconfirmed the need to 
implement these recommendations and reiterated the 
requirement for the Navy to improve its accountability and 
control over conventional ammunition. An in-house audit 
[ Ref. 6] conducted by the Naval Audit Service of small arms 
and ammunition programs reached similar conclusions 
concerning the CAIMS inventory accuracy. 

A. PURPOSE 

This thesis addresses the need to improve the interface 
between the CAIMS and the end-user. Specifically, it 
proposes a means to implement the GAO recommendations 
concerning timely and accurate transaction reporting and 
inventory reconciliation. The vehicle for achieving this is 
a system which automates the present manual recordkeeping 
and reporting functions at the afloat end-user level. This 
proposed system consists of data files and a software 
application program in a package termed the Ammunition 
Management System (AMS). 

Toward this end, the thesis takes the form of a software 
requirements specification. Such a specification, according 
to Pressman [ Ref. 7] , establishes a complete information 
description, a detailed functional description, appropriate 
validation criteria, and other data pertinent to 
requirements. The software requirements specification 
defines the user's needs for the software component of an 
automated data processing system. It concludes the planning 
phase and further serves as the foundation for the 
subsequent development and maintenance phases of the 
software life cycle. This generalized software life cycle, 
as defined by Pressman, is depicted in Figure 1. 1. 
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The common thread which binds the various phases 
together is user requirements. During the planning phase 
these requirements are identified and developed into 
characteristics of the desired software architecture. A 
translation then occurs during the development phase where a 
software product is formulated from the previously defined 
characteristics. The maintenance phase concludes the 
software life cycle and is evolutionary in nature. Here, 
the changes to user requirements drive the modification of 
the software product and ensure its currency and 
adaptability with the environment. This phase represents 
the most costly endeavor of the life cycle consuming up to 
seventy percent of an organization’s software budget. Fifty 
percent of this has been directly attributable to perfective 
maintenance of the original delivered product [Ref. 7:p. 

323] . This category of maintenance includes those actions 
to modify the software with new capabilities and general 
enhancements of initial capabilities in response to a 
changing environment and needs of the end-user. It is 
generally accepted that proper up-front research could 
reduce most of this cost. Therefore, the accurate 
determination of user requirements is intrinsic to the 
delivery of an effective and responsive software product. 
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Five questions have been formulated to assist this 
research effort: 

1. What are the functional user requirements of the 
proposed software? 

2. What are the required software design characteristics? 

3. What are the data requirements to support the 
application software? 

4. What are the validation criteria to test the proposed 
software? 

5. What are the possible sources of data? 

The answering of these questions, within the framework 
of software engineering, will not only serve to satisfy the 
requirements of the end-user but will also strengthen the 
system inventory management capability of the CAIMS, In 
this way data accuracy and reporting timeliness are enhanced 
at all levels of the CAIMS reporting structure. 

B. DISCUSSION 

Naval units are required to maintain records and submit 
reports covering conventional ammunition inventories in 
their custody. These actions form the interface between the 
fleet end-user and the CAIMS. Records maintained onboard 
enable the management of onboard inventories of ammunition 
and support the requirement for external reports about 
onboard ammunition. Onboard records are standardized by 
[Ref. 2] and include such items as the Ammunition 
Lot/Location Card, Ammunition Master Stock Record Card and 
the Ammunition Serial/Location Card. 

Reports, on the other hand, are tailored by Fleet 
Commanders to satisfy the unique reporting requirements of 
each fleet, in addition to satisfying the basic CAIMS data 
demands. These reports summarize data contained in records 
and are of a specialized nature. Such reports as the 
Ammunition Transaction Report (ATR), Maintenance Due Date 
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( MDD)/Missile Firing Expiration Date (MFED) Extension 
Requests and the Sonobouy Transaction Report ( STR) are the 
primary status reporting means of the fleet. In addition, 
other supply documents such as requisitions, followups, 
modifiers and cancellations round out the necessary 
capabilities for ammunition inventory management. 

Finally, as a closed-loop system, the CAIMS provides 
information to the end-user concerning the accuracy of user- 
generated reports and the material condition of onboard 
managed items. These include reconciliation reports 
originated by SPCC, and Notice of Ammunition 
Reclassification (NAR) messages originated by the systems 
commands. System effectiveness demands accurate input at 
the source. Accordingly, the onus for proper inventory 
status reporting begins with the end-user. Stated 
specifically: 

All CAIMS users have an obligation to pursue apparent 
errors in the CAIMS Data Base and ensure their 
reconciliation. ... To the extent that CAIMS data does not 
accurately reflect actual Navy assets, new ammunition 
procurements will not support fleet requirements. It is 
vital to recognize that fleet support for ammunition is 
directly related to the timeliness and accuracy of fleet 
transaction reporting into CAIMS. Therefore, accuracy in 
reporting cannot be emphasized too strongly . . . . [ Ref. 

2 : p. 8-1-2 ] . 

This overriding concern for timely and accurate data 
input at the source is included as a designed- in objective 
of the proposed software. As discussed later, this concept 
is implemented by various features that provide the 
requisite accountability over ammunition inventory stocks. 

C. SCOPE OF THESIS 

This research is limited to defining the software 
requirements of the end-user. Specifically, this thesis 
describes the application software necessary to automate and 
support ammunition inventory management and reporting at the 
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shipboard level. Accordingly, the unique requirements of 
ammunition load list management, as in the case of 
ammunition stores ships, is not addressed. A separate 
initiative in this area is the Fleet Optical Scanning 
Ammunition Marking System (FOSAMS) sponsored by the Naval 
Sea Systems Command. Interested readers are referred to 
[Ref. 8] for further project information. While the FOSAMS 
is not considered integral to this effort, interface 
requirements between the FOSAMS and the proposed software 
have been included in the functional description. 

A second consideration concerns the environment in which 
the program will operate. For practicality it was decided 
to integrate the system into the existing inventory 
management and reporting structure and not attempt to design 
an independent system for this purpose. Accordingly, the 
Initial Operating Capability ( IOC) will be limited in scope 
to the automation of current functions with the automated 
input and output resembling manual counterparts. In 
addition to achieving greater economy this action also 
reduces the need for retraining the ship's personnel. 
Flexibility is retained to allow program upgrades in 
subsequent releases. This will ensure program currency when 
procedures or policies change. 

Finally, this effort covers only conventional ammunition 
management. The unique management requirements of weapons 
covered by various Navy Special Weapons Publications (Navy 
SWOPs) and included in the reporting structure of [Ref. 9] 
are not addressed. The exceptionally high security 
classification ( Secret Restricted Data) assigned to these 
weapons, in addition to the low quantities of ammunition 
involved, does not lend itself to cost effective or secure 
automation. 
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E. METHODOLOGY 



This section establishes the framework for research and 
construction of the thesis. It is divided into three major 
areas covering the conduct of research, design approach and 
software metrics. 

1. Conduct of Research 

This research will follow generally accepted 
software engineering procedures with the end-product being a 
software requirements specification. The basic format of 
this thesis satisfies the provisions of [Ref. 10]. It is 
intended that this document serve as the basis for 
developing additional documentation to support follow-on 
design efforts on the proposed software. Accordingly, the 
onus is on identifying standard user requirements for an 
automated information system which is independent of 
software language or hardware configuration. In this way a 
more effective software design effort is supported. The 
proposed software may then be tailored, during the 
development phase, as either a stand-alone application or as 
an integrated subsystem in such standard ADP initiatives as 
the Shipboard Non-tactical ADP Program (SNAP). For this 
reason, SNAP compatibility is a design goal of the proposed 
AMS. 



As previously mentioned, the software requirements 
specification defines the user's needs for the software 
component of an automated data processing system. In 
determining these needs an extensive search was conducted of 
the many sources concerning ammunition management. 

This literature search was two-fold. First, a 
functional review of directives promulgated by Fleet 
Commanders and inventory managers was included to determine 
the existing inventory management and reporting policies. 
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Where possible. Navy training manuals and the author's 
personal experience served to supplement these procedures. 
The intent of this action was to take into consideration the 
"real life" or descriptive user environment. In this way a 
tempering of the software product is obtained thus realizing 
a higher probability of user acceptance. 

Second, existing system deficiencies were noted by 
reviewing the previously mentioned audits. This approach 
takes a normative view of afloat ammunition management as it 
should be accomplished given the framework of established 
policies and procedures. In addition to automating the 
present manual procedures, it is highly desirable to correct 
as many documented discrepancies as feasible. Again, this 
emphasizes the importance of the end-user link to the CAIMS 
reporting structure. Objectives of this effort are to 
facilitate more efficient reconciliation of reported 
discrepancies, enhance transaction tracking by the inventory 
manager and provide for greater accountability of ammunition 
assets beginning with the end-user. 

2. Design Approach 

The software will incorporate certain engineering 
principles to ensure program validity and reliability. The 
purpose of this section is to address the minimum measures 
necessary to meet these objectives. The ancient adage of 
"An ounce of prevention is worth a pound of cure" has more 
applicability to software projects than many other 
endeavors. Mills notes: 

It is well known that you cannot test reliability into a 
software system. If programs are well designed in both 
data structure and control structure there is no contest 
between a programmer and a computer in finding errors: the 

programmer will win hands down .... So the first 
defense against errors is well designed programs and 
preventive proofing by authors themselves. [Ref. 11] 
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Therefore, it is appropriate to address these engineering 
principles and the method of incorporating them in the final 
product. 



These principles have been derived by research 
efforts that are collectively referred to as "software 
engineering. " Comer identifies the aim of software 
engineering as to improve the programmer productivity and 
increase the reliability, correctness, and cost 
effectiveness of the final product [Ref. 12: p. 169]. The 
application of software engineering principles requires an 
established methodology. This methodology, according to 
Pressman [Ref. 8: p. 15] is an approach using a set of 
techniques that are application-independent. He provides 
three key objectives of this effort: 

1. A well-defined methodology that addresses a software 
life cycle of planning, development, and maintenance. 

2. An established set of software components that 
documents each step in the life cycle and shows 
traceability from step to step. 

3. A set of predictable milestones that can be reviewed at 
regular intervals throughout the software life cycle. 

The fundamental building block of software 
engineering is the concept of program modularity. In 
addition to providing the means for implementing other 
design concepts, modularity enhances human understanding of 
the program logic. This latter view enables "intellectual 
management" [Ref. 7:p. 152] or "conceptual integrity" [Ref. 

12: p. 268] of the software. 

Modularity is one aspect of structured design. This 
approach, according to Stevens and others [Ref. 13] is a set 
of proposed general program design considerations and 
techniques for making coding, debugging, and modification 
easier, faster, and less expensive by reducing complexity. 
This is achieved by subdividing the software system. The 
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problem is decomposed into required functions and then 
refined ("stepwise refinement"). These functions are then 
translated into groupings of software code (modules) that 
are separately named and addressable. These elements are 
then integrated into a program structure to satisfy the 
problem requirements. 

Modules may be characterized by "functional 
strength. " This is where modules are designed to address a 
specific subfunction or task of the total requirements 
package. The measurement of the degree of functional 
strength of the module is called cohesiveness [Ref. 7;p. 

158] . Complexity is reduced when modules have a high degree 
of cohesiveness. This allows for the concept of 
"information hiding" to be implemented whereby only data 
necessary for a given module to function is made available 
to that module. This data is "hidden" from other modules 
that do not have use of it. In this way program control 
paths, entry points and data availability are reduced with 
an increase in overall program independence. 

Module cohesiveness also can impact memory 
efficiency and the speed of program execution. According to 
Peterson and Silberschatz [Ref. 14] a program is divided 
into "pages" which are loaded to memory "frames. " These 
pages determine the locality of program execution. 



The locality model states that as a program executes, 
it moves from locality to locality. A locality is a set 
of pages which are actively used together .... A 

? rogram is generally composed of several different 
ocalities which may overlap. 

For example, when a subroutine is called, it defines a 
new locality. In this locality, memory references are 
made to the instructions of the subroutine, its local 
variables, and a subset of global variables. When the 
subroutine is exited, the process leaves the locality, 
since the local variables and instructions of the 
subroutine are no longer in active use .... 

(L)ocalities are defined by the program structure and its 
data structures. The locality model states that all 
programs will exhibit this basic memory reference 
structure. 
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From this example it is evident that the more 
cohesive a module the higher the probability will be that 
necessary information will be in memory to support execution 
and the need to search for other pages is minimized. 



Another qualitative criteria of module independence 
is coupling. Stevens and others provide the desired design 
objective in this area: 

The complexity of a system is affected not only by the 
number of connections but by the degree to which each 
connection couples (associates) two modules, making them 
interdependent rather than independent. Coupling is the 
measure of the strength of association established by a 
connection from one module to another. Strong coupling 
complicates a system since a module is harder to 
understand, change, or correct by itself if it is highly 
interrelated with other modules. Complexity can be 
reduced by designing systems with the weakest possible 
coupling between modules. [Ref. 13: p. 117] 

More consideration of coupling will be provided in 
the internal interface section. For now the previous 
discussion is adequate to continue the examination of other 
software engineering principles. 

With the proper construction of individual modules 
ensured by adherence to cohesion and coupling objectives, we 
can now attend to design of an integrated program. This 
section concerns the design topology of the program 
structure. Methods of integration are discussed later in 
the validation criteria chapter. 

Program structure denotes hierarchical control from 
the top-down. Control relationships may by depicted in a 
box diagram, such as Figure 1.2, where each box represents 
an independent module. In this diagram, control is 
"factored" down from superior to subordinate modules. 
Pressman [Ref. 7:p. 149] mentions that in this way design 

and implementation are simplified, testability is enhanced, 
and maintenance can be approached in a more efficient 
manner. 
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Figure 1. 2 

Program Structure Diagram 
( Example ) 



While Pressman stresses that there is no single 
correct approach to factor control in a program, he does 
provide eight design heuristics, or guidelines, that enable 
successful design. He further notes that application of 
these heuristics is independent of a specific design 
methodology. [Ref. 7;pp. 169-174] 



1. Evaluate the preliminary software structure to reduce 
coupling and improve cohesion. 

2. Attempt to minimize structures with high fan-out; 
strive for high fan-in as depth increases. 

3. Keep scope of effect of a module within the scope of 
control of that module. As an example, if a variable s 
value is changed during module execution, the results 
of that effect should be limited to those modules under 
the control of the module making the modification. 

4. Evaluate module interfaces to reduce complexity and 
redundancy and improve consistency. 

5. Define modules whose function is predictable, but avoid 
modules that are overly restrictive. 

6. Strive for single-entry, single-exit modules, avoiding 
"pathological connections ( i. e. , multiple entry 
points ) . 

7. Package software based on design constraints and 
portability requirements. 

8. Select the size of each module so that independence is 
maintained. 
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These heuristics have been incorporated into the 
planning effort of this project. 

The treatment of design approach in this section has 
been intentionally cursory in nature. The intent was to 
address major software design concerns which can affect the 
planning phase and not bog down in the details of the 
various divergent views on this subject. In the next 
chapter the concept of data flow-oriented design is 
presented. The objective of this method is to derive a 
software architecture through the translation of information 
flow. 

3. Software Metrics 

The previous section discussed preventive measures 
that are to be designed into any viable software program. 
However, these methods, in themselves, do not provide an 
indication of the resulting program complexity which can 
affect such things as development cost and process 
efficiency. Both of these have major impact on the ultimate 
success of the software. To provide a more complete picture 
of the software, various software metrics have been 
developed. In this section we will discuss representative 
metrics and their application to the program at hand. 

A metric is defined as a measurable indication of 
some quantitative aspect of a system. DeMarco lists five 
such quantitative aspects requiring measurement in a typical 
software project. These are scope, size, cost, risk and 
elapsed time. He further allocates metrics into one of two 
categories as either a result or as a predictor. [ Ref. 

15: pp. 49,50] In the development phase of the software life 
cycle we are more concerned with the use of metrics to 
predict and enhance the productivity of the software 
development effort. The wealth of literature on software 
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development relates to the estimating of software 
productivity effort. Not surprisingly, the management tools 
available for this purpose are extensive [ Ref. 16] . 

However, the availability of metrics to predict software 
quality are more elusive [Ref. 7:p. 164]. Of these metrics,’ 

the cyclomatic complexity measure and software science show 
the most promise, albeit still in their infancy. Both of 
these methods satisfy the major functions of a software 
metric as defined by Curtis [ Ref. 17] : 

1. Serve as a management information tool. 

2. Serve as a measurement of software quality. 

3. Provide feedback to the software engineer. 

The first metric is the cyclomatic complexity 
measure proposed by McCabe [Ref. 18]. His efforts serve to 
answer the question: "How to modularize a software system so 

the resulting modules are both testable and maintainable. " 
The metric he develops uses the number of control paths 
through a program as a measure of complexity. For example, 
a program segment ^s represented as a process graph (G) in 
planar space and is depicted in Figure 1. 3. The cyclomatic 
number v(G) is the effective metric computed by the formula: 



v(G)=e-n + p 



where e is the number of edges, n is the number of vertices 
of the graph, and p is the number of connected components. 
The nodes of the graph represent modules of software code. 
For the graph in Figure 1.3 v(G) is equal to 4. This is 
computed from the above formula as follows: 
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v(G) = 7- 5 + 2 = 4 



For a strongly connected graph (with unique entry 
and exit nodes) v(G) is equal to the maximum number of 
linearly independent circuits. Stated another way, the 
cyclomatic metric may be computed by counting the enclosed 
regions and adding one for the surrounding area. 




McCabe describes the application of this metric as 



follows: 



The overall strategy will be to measure the complexity 
of a program by computing the number of linearly 

4. programs by 

j just 

,, ^ :y as the 

basis for a testing methodology. [Ref. 18: p. 309] 




Based on experience gained from observing 
programmers involved in differing software projects, McCabe 
set this upper limit at ten. This figure was based more in 
reasonableness rather than magic. Although the intent was 
to limit the size of modules and allow for testing of all 
independent paths, this approach had an additional positive 
affect. The metric enforced a discipline on the programmer 
to follow structured programming rules. McCabe noted that 
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even programmers who had no formal training in structured 
programming consistently produced code in the 3 to 7 
complexity range. 

At this point one may wonder why we are even 
discussing McCabe's complexity measure since it deals with 
modules of code and the actual coding doesn't begin until 
the development phase of the life cycle. The answer lies in 
the need to predict and limit the program complexity and 
properly identify resource requirements early-on. The 
concept that enables application of the complexity metric at 
this point is the abstract process. 

Mekly and Yau [Ref. 19] define an abstract process 
as a representation schema for a discrete phase of system 
activity directly associated with some function and 
identifiable by the initial and final states with respect to 
that function. Pressman expands this to include various 
views of the same system: 

When we consider a modular solution to any problem, 
many levels of abstraction can be posed. At the highest 
level of abstraction, a solution is stated in broad terms, 
using the language of the problem environment. At lower 
levels of abstraction, a more procedural orientation is 
taken .... 

Each step in the software engineering process is a 
refinement in the level of abstraction of the software 
solution .... (T)he lowest level of abstraction is 
reached when source code is generated. [Ref. 7:pp. 

154, 155] 

The concept of the abstract process supports 
development of abstract process networks (AP-nets) which, in 
their basic sense, serve as "software blueprints. " The AP- 
net is a representation of the software system and indicates 
operations on system control and data transformation. Mekly 
and Yau [Ref 19: p. 431] note that the "orthogonality" of 
control and data flows in an abstract process allows AP-net 
use to represent system characteristics in terms of either 
control or data flow. This observation has permitted the 
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application of the complexity metric in designing Data Flow 
Diagrams (DFDs). The DFD is essentially a graphic tool used 
to depict information flow characteristics. The application 
of this technique is discussed in the next chapter. 

The second area of software metrics has been 
proposed by Halstead [Ref. 20] and is called software 
science. This method provides a highly quantitative 
measurement approach which views software from many 
perspectives including program length, volume, level and 
purity. Although the major thrust of this work is result 
(vice predictive) oriented, it is included for its potential 
use as a formal measure of program size and resulting 
complexity. As such, it can be used to develop a design 
approach in the planning phase. In the development phase 
software science can assist in the selection of a target 
language which maximizes the efficiency of implementation 
for a given application. 

The effective metric for this purpose is called the 
program level (L). It has its genus in the following: 



Intuitively, the concept of the level at which a 
program might be written has been with us since the first 
Higher-Level Languages were referred to as such. Before 
a concept of this type can have much scientific utility, 
however, it must be reduced to quantitative or measurable 
terms .... (O)nce a given algorithm and a given 
language are decided on, alternative implementations may 
be comparatively ranked only on the basis of expert 
opinion, or perhaps by the opinionated experts. Yet it is 
quite true that the level of implementation is vitally 
important in programming, because it contributes to the 
effort of writing, propensity for error, and ease of 
understanding. [Ref. 20: p. 25] 



The program level of the implementation of an 
algorithm is defined as: 



L = 2/n 1 X n 2 /N 2 
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where the primitive measure rj ^ is the number of unique 
operators that appear in an algorithm; r\ 2 is the number of 
unique operands that appear in an algorithm; and N2 is the 
total number of operand occurances. From this relationship 
a tradeoff may be determined and a language selected that is 
optimal to the application at hand. A language which 
decreases the number of unique operands in relation to the 
number of unique operators ( for a given application) would 
result in a lower program level. The "algorithm" for our 
purposes would be the data flow diagram, again applying the 
concept of abstraction. 

In theory, this algorithm must be capable of 
implementation in some minimum volume. In this case, the 
program level equals one and represents the most efficient 
implementation feasible. A caveat must be introduced at 
this point, however. Effective usage of the program level 
metric in the planning phase requires that reliable data be 
available from sample implementations of similar algorithms. 
Only in this case can alternative algorithms be compared and 
an implementation strategy selected. 

The program level metric is not operational in the 
planning phase, per se. The basic reason for this is that 
implementation is not an objective of this phase. This 
metric does serve an important planning function, however, 
and deserves mention here. The program level forces 
consideration of the design requirements of the following 
development phase. In so doing, simplicity and efficiency 
are introduced at an early stage of requirements planning. 
This is reflected in the economy of the data flow diagrams 
presented later ( i. e. , minimizing the number of nodes per 
level) and will pay off in easier coding, testing and 
maintenance later on. 
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II. INFORMATION DESCRIPTION 



During the planning phase, user requirements are 
identified and then translated into desired software 
characteristics. This process results in the definition of 
functional program capabilities and the necessary software 
architecture. This chapter concerns the first of two 
intermediate steps essential in this transformation process. 
This is the analysis of information flow. The software 
engineering methodology for this purpose is a process called 
data flow-oriented design. The objective of this method, 
according to Pressman, is to provide a systematic approach 
for the development of software structure, an architectural 
view of software and the underpinning of the preliminary 
design step [Ref. 7:p. 178]. He further notes that this 

transition from information flow to structure is realized in 
a five step process as follows [Ref. 7;p. 180]: 

1. Information flow category is established. 

2. Flow boundaries are indicated. 

3. Data flow diagrams are mapped into software 
architecture. 

4. Control hierarchy is defined by factoring. The term 

factoring means distributing control among software 
modules from the top-down. 

5. The resulting structure is refined by the use of design 
measures and heuristics. 

These steps are performed by first deriving the data 
flow diagrams and data structures necessary to support 
graphic depiction of the information flow. Secondly, a data 
dictionary is provided to describe the data environment of 
the software and to establish standards for data element 
representations or definitions. A data acquisition strategy 
is then proposed. In keeping with the previously stated 
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design goal of compatibility with the SNAP, the proposed 
method of data acquisition follows the established data 
draw-down and build procedures. Finally, a program 
structure is derived with a control hierarchy factored among 
independent modules. 

A. DATA FLOW DIAGRAMS 

As previously mentioned, the DFD is a graphic -tool used 
to depict information flow. The DFD occupies an invaluable 
place in most software engineering methodologies. It is 
this building block that is used to map the desired software 
structure into the data flow-oriented design discussed 
later. In addition, by applying the concept of AP-nets to 
the DFD, an incremental refinement may be accomplished for 
process representations beginning with the highest level 
representation and continuing down through the lower levels. 

The construction of the DFD is relatively simple and 
requires only four constructs. These are summarized as 
follows: 



Information ( i. e. : data flow) is represented by a labeled 
arrow. Processes (transformations) are represented by 
appropriately labeled bubbles. Information sources and 
sinks are noted as labeled boxes, and stored information 
( e. g. : a data file) is represented by a double horizontal 

line. An information source is a location where data 
originates .... An information sink is the final 
destination of data as it moves through the system. [ Ref. 
7:p. 101] 



Pressman [Ref. 7:p. 101] notes three attributes of a 



DFD: 



1. Information flow in any system- manual, automated, or 
hybrid- can be represented. 

2. Each bubble (node) may require significant refinement 
to establish complete understanding. 

3. Flow of data, rather than flow of control, is 
emphasized. 
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The last attribute, flow of data, is an important 
concept at this point. The DFD only displays logical 
processes and does not indicate control hierarchy. The DFD 
is related to program structure, however, through the 
previously mentioned mapping process. This process is the 
translation of the flow of data ( represented by the DFD) 
into a control hierarchy ( represented by software structure 
diagrams). 

For the application at hand, the analysis begins with 
the Fundamental System Model depicted in Figure 2. 1. This 
is the most basic level of abstraction where the entire 
system function is represented by a single node, or 
information transform. The "black box" approach provides 
for a system overview of information inputs and product 
outputs. In addition, it serves as an intellectual starting 
point for subsequent refinements to the system. 




*File descriptions are provided by logical 
record formats in Table 1 on page 41. 
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Appendix A provides data flow diagrams which are 
refinements of higher level models. That is, the Level 1 
model is a refinement to the Fundamental System Model, Level 
2 models are refinements to Level 1 models, and so forth. 

The logical boundary of a process that is included in a 
given refinement is called the "domain of change. " 

The domain of change supports and builds on the concept 
of the abstract process. In this way, high level models 
need give only cursory detail of process functions and data 
flows. These models may later be refined, within a domain 
of change, as user requirements are clarified or when 
pending modifications are implemented. The rules for model 
refinement are governed by the characteristic of the process 
being represented by the node. A process may be 
characterized as either a data transaction ( i. e. , Select 
Function) wherein data is changed as a result of a 
triggering action, or as a data transform wherein data is 
modified along a path over a period of time. 

The distinctions between transaction and transform 
analysis will not be included here. The reader is referred 
to [Ref. 7:pp. 182-197] for an intensive handling of this 

subject. Some general guidelines to be followed during 
model construction and refinement are [Ref. 7:pp. 102-104]: 

1. The first data flow diagram layer should always be the 
fundamental system model. 

2. Primary input/output ( I/O) files should be carefully 
noted. 

3. All arrows and (nodes) should be labeled (with 
meaningful names). 

4. Information continuity must be maintained. That is, 
input and output to the refined model must remain the 
same as in the original model. 

5. One (node) at a time should be refined. 
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B. DATA STRUCTURE REPRESENTATION 



A data structure may be informally defined as an 
organized collection of values and a set of operations on 
them [Ref. 21]. A data model is an extension of this 
concept. It provides a method to organize, represent, 
access, store, modify and process the data. Sprague and 
Carlson [Ref. 22] identify five data models of which four 
may be used in this effort. 

We will discuss the record and relational models in this 
section. The former is the oldest and most common approach 
to data organization, the latter being the most state-of- 
the-art. 

The record model is the traditional approach to data 
organization and has found wide acceptance and use in 
business and military non-tactical applications. In this 
model, data is organized into files in order to support 
specialized application programs. This scheme is depicted 
in Figure 2. 2. For the proposed AMS we would require four 
separate files with associated application programs. The 
files contain records, which in turn are subdivided into 
fields. The records are identified by one or more fields, 
called keys, which contain unique values, i. e. , different 
values for each different record. 



Although this is a straight forward approach to 
processing, it is susceptible to what is referred to as data 
modification anomalies. As an example, if it was necessary 
to add a field to the Ammunition Management File, the 
associated inventory program would have to be changed and 
updated. But the problem does not end there. The 
Ammunition Requisition File and program would also have to 
be updated to reflect this change even though the data field 
may not be used in that processing activity. 
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Another problem occurs when data is lost. This is 
called a deletion anomaly. If, for example, the unit price 
of an item is only shown in the Requisition File, and the 
only outstanding requisition for an item is received or 
cancelled, we lose the unit price data for that item. 



In response to the data modification anomaly problems of 
the record model, the relational model was developed. In 
this scheme, data is organized into files according to rules 
called "normal forms. " There are currently seven such 
normal forms identified [Ref. 23], however, most data design 
efforts are limited to satisfying the first three. These 
are: 



1. A relation cannot have any repeating groups (fields). 

2. Attributes (fields) must relate to the primary key. 

3. Attributes must only relate to the primary key and not 
to any other field. 

The higher level normal forms are not used because it 
would require more money to implement them than is required 
to accommodate the anomalies which would remain. 
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In the relational model, data is organized into 
"relations." The relation is a construct of "attributes," 
or fields, that are functionally dependent on the primary 
key. It is this concept which provides the much needed 
independence between files and the associated reduction of 
modification anomalies. The discussion of relational 
database theory goes beyond the scope of this paper. A good 
overview of this topic is provided in [Ref. 24] and [Ref. 

25). In addition, the reader is referred to [Ref. 26] for a 
discussion of the normal forms and their application. 

A side effect of using the first three normal forms is 
that they tend to proliferate relations. In fact, the 
number of relations increase significantly with each attempt 
to incorporate a higher level normal form in the data base 
design. The motivation for this, however, is that the 
relational data base management system offers greater data 
accessibility and flexibility. Through the mathematics- 
based set operations characteristic of the relational data 
base system more data is made available to the user and 
greater efficiency is provided over standard file processing 
systems due to the reduction in data redundancy. Figure 2. 3 
demonstrates this capability. 
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The files shown in Figure 2. 3 are described by their 
logical record structures in Table 1 ( p. 41). In order to 
retain flexibility in describing the data structures, these 
records are presented in a "pseudo-COBOL” hierarchical 
structure. This enables better understanding of the record 
contents and data relationships. In addition, this approach 
permits easy translation into COBOL record format as well as 
database relations. 

Provisions for COBOL record format translations must be 
made. First, COBOL is presently the Navy's standard 
business computer language. Second, this approach 
facilitates enhanced data understanding by systems analyst 
and programmer personnel, a majority of whom are COBOL 
literate. 

The logical records presented in Table 1 satisfy the 
first three normal forms with the exception of the 
Ammunition Constants File (ACF). The unique application of 
this file does not lend itself to normalization beyond the 
first normal form. Update anomalies are avoided, however, 
in that only one record resides in the file and that data 
elements are not found in other files. 

C. DATA DICTIONARY 

The data flow diagrams provide a blueprint of 
information flow in terms of data transformation and 
transaction. The data description proposes a logical data 
structure to support this process. The purpose of this 
section is to define the data elements themselves. The 
vehicle for this is the data dictionary. 

The data dictionary provides meaning to the data 
represented in the data flow diagrams. It defines data 
elements and provides such characteristics as allowed values 
(codes, etc.), aliases, supporting references, and 
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identifies user programs. In addition, as a design 
document, the data dictionary serves as an important project 
reference that allows standardization at an early phase of 
the life cycle. This capability enables program portability 
and easier maintenance. 

It is this last reason that the Standard Data Element 
Dictionary ( SDED) [Ref. 27] was developed. The SDED is 
published by the Navy Fleet Material Support Office as a 
reference document for designers of uniform automated data 
processing systems, systems analysts, and programmers for 
identifying and obtaining COBOL descriptions of data 
elements used in NAVSUP managed data processing systems. 

The CAIMS is included within its scope. 

In keeping with the emphasis for standardization, the 
AMS data dictionary (Appendix B) utilizes standard data 
element names, where applicable, from the SDED. Local data 
elements are defined using the SDED entry format in Table 2 
(p. 46). The data dictionary is a dynamic document and will 

require frequent revision during the development phase as 
new elements are identified. In addition. The AMS data 
dictionary only contains those data elements included in the 
logical record structures. Global and local program 
variables that are not associated with a logical record also 
require definition. These should be entered prior to actual 
coding, preferably during the process narrative 
("pseudocoding") step of the development phase. 

D. DATA ACQUISITION 

The acquiring, formatting and integration of data can be 
an expensive and time consuming task. The extent of this 
effort cannot usually be determined a priori. This is due 
to the fact that there is no standard software 
implementation to provide a benchmark. There is, however. 
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general agreement that the existence of data prior to 
development significantly reduces both cost and effort 
involved. 

Sprague and Carlson [Ref. 22: pp. 223-225] provide an 
example of this effect in the implementation of a decision 
support system. He noted that in those implementations 
where preexisting data was not available the cost of data 
acquisition amounted to over fifty percent of implementation 
costs with ten percent of manhours devoted to data 
validation or correction. These same figures were reduced 
to less than ten percent of implementation costs and less 
than one percent of manhours when a preexisting data base 
was available. These facts present a strong argument for 
the use of established data repositories. 

For the AMS project, this repository is the current 
CAIMS data base and the local records maintained by the 
ship. Such an approach is not new. CAIMS summary reports 
are presently available to inventory manager and Fleet 
staffs by Navy Ammunition Logistics Code (NALC) or DOD Item 
Code (DODIC) [Ref. 28]. This information includes balance 
quantities (serviceable/unserviceable), allowance, and 
monthly and cumulative expenditures by type (combat, 
training, etc. ). A "draw-down" of this data could be 
conducted and a data base constructed that is tailored to a 
specific ship. This approach parallels the data acquisition 
strategy for the SNAP II where the Weapon Systems File is 
used to construct shipboard data configuration files. The 
ability to integrate these two draw-downs is possible. Such 
an accommodation would allow the AMS to be implemented as a 
subsystem in the SNAP II. Figure 2.4 ( pp. 39,40) depicts 
the CAIMS/local data acquisition overlayed with other SNAP 
II data. The local data provided by the ship would augment 
that provided by the CAIMS draw-down and include that data 
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which is not available such as responsible work center and 
location. 

In addition to simplifying the data acquisition process, 
this strategy would have the added benefit of protecting the 
integrity of the CAIMS as the sole repository for all 
ammunition stock status. From lessons learned in numerous 
SNAP II installations, errors are best identified and 
corrected at the end-user level. Following implementation, 
the ship should be required to conduct a review of its CAIMS 
reported allowances and stock balances. Automatic ATR/STR 
documents could then be produced incident to data correction 
in a way similar to the way that configuration change 
reports are now produced by SNAP II. This is implemented by 
protecting the various records through the application 
software. If changes are made by users to these records, 
and if such changes fall under externally reportable 
criteria, the software flags these changes and includes them 
in subsequent report generations. This process is conducted 
automatically and is invisible to the user. 

E. PROGRAM STRUCTURE 

The derivation of the program structure is a major 
objective of the planning phase. This translation from the 
data flow diagrams, presented earlier, operationalizes the 
design heuristics as they pertain to functional cohesiveness 
and coupling, and to factoring of control and modularity. 
These structures are provided in Appendix C. 
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